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14. SOME QUOTES FROM INFOWORLD culled by Don Rhodes 

LOOK--FAYATTBfnOH— --the next SBUCmee ting will be held at the 
Cupertino Library. 

Time: 7:15 - 9:30 PM 

The next 3 meetings will beheld on March ISth, April 15th and May 20th. 

NOTE THIS NOTE 

For those of you lacking ihe proper number of flngen and toes, meetings are held 
on the third Tuesday oT each monCh, 

Chris Oman will continue to jpeak on conmunlcatlons. The editor will resume Ms 
conferencing for his peers, thie semi-educated. . 

ljOaKfOjaRBCAitDE2I::Ort« M 
to mlirilK *• SKS. ^ed 
^ a ftHXK cm*. A COCO 



MEMBERSHIP 

If you wlA to become a member of SBUC and start receiving our newsletter t}YNAMIC 
MEMOR lES", then send $20 (check or money order) to the following address; 

South Bay TRS-M Usen Group 
P.O. Box 60116 
Sunnyvale, Ca. 94068 

or come to one of our meetings. If you also wlA to conmunlcate with our bulletin boanl 
system (SBUG-SO) then Include an additional $25 (a one time fee) for an account on the 
system. You must be a member of SBUG to have an account on the system. Please Include 
your address and phone number. 

1111111111111 f111111111111111111111l11l1111111l1f If 1111111111111 

COPYRIGHT (C) 1985 SOUTH BAY TRS-80 USERS GROUP (SBUC) WORLD RIGHTS 
REERVED. NO PART OF THIS PUBLICATION MAY BE REPRODUCH) WITHOUT 
GIVING CREDIT TO IHE AUTHOR AND SBUC. REPRODUCTIONS MAY ONLY BE 
PERTORMED BY NONPROFIT ORGANIZATIONS. PROFIT MAK INC ORCANIZAI IONS 
MUST HAVE PRIOR WRITTEN PERMISSION OF THE EDITOR. 
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MEMBER 


USERNAME 


PHONE 


Chalmwi: 






ChrlBOnwi 


OMAN) 


(400) 985-9460 


Treasurer 






Don Rhodes 


(DON) 


(408)996-1006 


Secreuiy 






Jbn Gonaalves 


(MANOR) 


(408)241-9347 


Newdetcer Editor 






Joel Lee 


(EDITOR) 


(408)926-3999 


UbrarluiK 






(iJIk] Bemie Thompaoii 


(BLKNIE) 


(406)867-7455 


(docs) Gai7 Dixon 


(GDIXON) 


(408)262-6937 


SBUG-SO SyK^is: 






SYSOP 1 k COEDITOR 






Geriy McKee 


(Ceny) 


(408)752-3207 


SYSOP II 






Don Rhodes 


(Don) 


(408)253-6293 


OTtKR KEY INDIVIDUALS 




Cover Artist: 






No, It was not Rubens 






Host Computer: 






SBUC 


(ALL) 


(408>4MirtiM 


If the need arises, feel fiee to give any one of us ■ call. 





T«: EDITOR'S BYTES AND BITES 

Mjr Model 4 ndl re now a alacrity In this dutk I feel like IsMloie Scfawsnz at 
the MeMlowbiDok Coaauy Chrii^ like JesK Owens m a meeting of HKlv jrouth. Never 
niiKl, we will strvlve, like all ate>rlties oar culture Is the stronger for being Isolattd and 
Ignored. 

Our bulletin boaid It carrently a frail flower langulAlng In die shadows. Why? 
Well, It needs watering. It needs fertlllxer (there'senough of diat in this club). 

Someone said that diere wv no reason lo pay when there are dozen of boards 
locally avsllaUe ::free ::Thst^ not all the arawer. Even the members who have paid are 
not accesring the board. It's partly a guestlon of ttme. We got out of the habit of getting 
on the boaid during itt late infirmity. 

A private board has Its advmtagea. Private messages may be exchanged, people 
who know each other may cconnnlcaM when face to face dealings are not possible. la 
die mantfane we will have m make a fecial effort. SUPPORT YOUR LOCAL BOARDI 
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sue Financial SlKentait 
February 28, 1986 



Receipts 


February 


Y-T-D»te 


%Uaed 


Budget 


Irfembers dues 


180.00 


351.00 


35.1(M 


looaoo 


SUCmS Cbei 


OlOO 


aoo 


aooib 


2oaoo 


Dtrii Library 


16.00 


16.00 


I3.3M 


i2aoo 


LoedSO 


96.00 


96.00 


48.00)b 


2oaoo 


Elocunienutlon 


aoo 


aoo 


O.OOK1 


4aoo 


bite re It 


0.00 


3.M 


U.SGK 


3aoo 


Total Receipts 


292.00 


466.54 


29.34Ni 


1590.00 


DIaburaements 










Phone 


36.06 


58.98 


24. 5M 


24aoo 


UUIttea 


OlOO 


40.00 


I5.)9tfa 


264.00 


Prtndns 


75.50 


172.87 


48.0M 


36a00 


Poitage 


4ara 


saw 


3XZ» 


isaoo 


POBox 


0.00 


aoo 


aooib 


26.00 


Bank crharfei 


aoo 


aoo 


aoo 




Uak Ubrary 


aoo 


aoo 


aooib 


50.00 


Dtxnimentation 


aoo 


aoo 


aooh 


8aoo 


SUGEBS 


aoo 


aoo 


aooh 


2oaoo 


Total DUfauraenients 


151. S6 


331.85 


23.49% 


I37a00 


regln Carfi Belmce 


52187 


5 1^62 


loaooib 


519.62 


Net Receipts 


I4a44 


144.69 


65.77% 


220.00 


Ending Balance 


664.31 


664.31 


89;82h 


739L62 
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SOMt NOTES FROM Tl IE ELEGANT EDITOR'S PLUSH OFFICE 

Yearly dues have been raised to $20.oa Pa-manent membership nn the bulletin 

board Is still S25.00. (LOOK, LOOK. LOOK That is a one time fee.) We are 

thinking of offering non-club members the uk of the bulletin board for a yearly fee. The 
steering committee made no final decision on this. Po&slbly it could be threshed out at a 
full club meeting. 



........ Computer User Croups ..-■..----. 

By the much quoted DON RHODES 

In "Personal Computing", February, 19S6, there's an article called TIaers Groups 
Get Down To Business." The article says that U.C.s are for computo' enihusiastsand are 
also playing an increasing roll In providing education forbudrwss. 

Business people now have PCs at tbetr offices and some are getting a second one 
for home. Tite U.G.s provide a mesm for them to obtain additional tips and instructions 
that Is hard to find in all those manuals; provide a place to exchange Ideas and find 
solutions to problems. 

The largest U.G., Boston Ccnpuier Society, has about 1.000 members with SIGs 
(Special Interest Groups) f<r many aspects of using siftwaie and hardware: dBAS SIG, 
Lotus SIG, ( well you get die Idea). The largest SIG with 400 Is PACS, an Apple SIG. 
Silicon Valley Computer Society (SVCS), In San Jose had reached about 200 members and 
now its' membership b dwindling to 150. ( Why that souncb like SBUC !). Why die 
decrease In memberships? Why Is the Boston ComputO' Society going strong while SBUG 
and the SVCS are on the decline? 

You would think that Silicon Valley would have the largest user groups In the 
world... Isn't this the place computers were born? The hey day of user? groups hasi't 
passed, the role of the successful user group has changed to one of "how the chips work" 
to that of "how does a compuia' work." Today's computer user Is not an engineer, a 
hacker nor a computer scientist. He or she most likely has a computer because they know 
some one else that has one and realty Just wants to get results out of it. 

Don't ytw thtnk SUG could change to a form that would liKerest this new breed 
of computer user? Couldn't we provide public education for "Just plain folks" that want 
lesil ts atid not have to learn programming cr how a disk ik'lve works? We as a club have 
years of experience behind us. Can we convert that experience Into conveyable 
knowledge to be disseminated among new users? We could help them solve irobifnns. use 
software, learn to use the modem, where to get repairs? Are you wilting to share on that 
level? 

Or, Is SBUG going to sit back and watch Its demise? 

Frank Mayhar 

12/29/85 

Sephen F. Austin State University 

FIDO 124/16 
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A SUGGESTION FOR A NEW FILE THANSTER PROTOCOL 

Thli vllcle Bdck-eBsei the (roblena Inherent tn Ward Ctirkstenaen's original 
XMODEM protocol, which ve not entirely nived by any of the new protocols that huve 
been Intioduced since. It then propoaea ■ new protocol that would be a natural siccessor 
to the XlulODEM protocol, and that may provide mote effective long-term solutions 
to those problenis. 

Irtroductlon 

[ have used Ward Christenaen's XMODEM protocol for aeversi years. In that time 
I have become aware of (actually, I have run head on Into) several problems with It. 
These probtetna are mostly solved, to a greater orlesaer degree, by many of the current 
new crop of protocols that have beenlntroduced In the peat few yeara. However, the 
methods by which they have been solved are less than might be desired, and Introduce 
new proMenis, mostly of compatibility with existing file transfer methods. 

The Problems 

Tlie [roblen« I am referring to arc (1} the total lack of a way to trsmfer file 
Information (file name, length, cteatlon date), (2) relatively potr data throughpiM, and 
(3) very pocr performance of most software at high data ratea (I.e. rates greater than 
about 1200 to 2400 baud). 

The flrvt problem Is self-evident In the protocol definition Itself. Ward 
Christenaen provided no way to transfer file Information. 

The second problem has to do both with the theo-etical efficiency of the protocol, 
and with the efficiency (<r lack thereof) of the Implementation. Hie theoretical 
efficiency of a protocol Is determined by dividing the number of bits or actual data by 
the total number of bits transmitted. The obvious way to Increase such efflclerx:y, then, 
is to Increase the amount of data transmitted relative to the amount of control 
Information traismltted. The straight XMODEM protocol (using 128-byte blocks) ranges 
from about 95% efficient In the worst caae, to about 96% efficient In the best case. 
(The best case occurs when the number of data bytes fits evenly Into the trananltted 
blocks] [the nie length Is evenly dlvlriUe by the block length, 128 tn this easel. The 
worst case Is when the last block trarsmltted contains only one actual data byte plus 
flMer for the rest of the block.) The efficiency of the same protocol lalng 1024-byte 
blocks ranges from 99% In the best case to 93% In the worst case. Efficiency Is lowered 
In any case, of course, if errors occur. The average XMODEM efficiency is, 
theiefoie, around 96%. The average efficiency when using 102'4-byte blocks Is also 
atoimd 96%. 

So increasing the block length Is no solution to the theotetkrat efTlctency pnMem. 
A better solution would be to use variable-length blocks (say varying between 128 and 
1034 or 2048 bytes). This may also help solve another problem. 

The major problem whh the actual effective data throughput of most XMODEM- 
type file transfers has to do with the efficiency of the software doing the transfer. 
In any transfer, the tlvoughput of the transfer Is controlled by the ^eed of the 
least efficient ride of the transfer. 
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UsiaJly. Bt 300 v 1200 (or even 2400) baud, the Inernclency oT most auTtware is 
not notlceabJe. hlowever, when Ibe data rate Is Increased, the Inef nciency of most of the 
software make the effective throughput stay around 1200 or 2400 baud, at best. (Then 
are notable exceptions to this, particularly Greg Gllley's TERM terminal emulator 
program for the TE Pro, which Is the absolute best I've seen at this. There may be others 
thai I'm not aware of.) 

Although the best xilutlon to thb problem would be to optimize the efficiency of 
the software, this may not be feasible In all cases. Longer or variable block lengths, 
which Increase the efficiency of the protocol and make the software spend more time 
actually transmitting blocks rather than processing, would undoubtedly help, even If It 
wouldn't completely v>tve the problem. 

In addition, th«e Is a problem that st«ns fran the attempts by a very large 
number of programmers to solve the problems outlined above. This can be summed up In 
the statement that none of the current file transfer protocols provide any convenient way 
for the receiving and transmitting programs to reconcile what extensions to the 
XMODEM protocol will be used in the currert transfv. (These exteiBlors include CRC 
error checking (rather than the checksum method used In the original XMODEM], and 
larger data packets [as In the relatively new YMODEM protocol, which provides 1024- 
byte data packets to Increase through put].) A compatibility problem also exists between 
different XMODEM-based protocols, such as Tellnk, MODEM7, and YMODEM. 

The cirrerK methods to sccon^lih some reconclllacion between receiver and 
sender range In most new XMODEM-based protocols firxn mnexlstent to the "C -Instead - 
of-a-NAK" method for euabtlshing CRC trrcr checking, and different characters 
(Instead of SOH) as packet prefixes tn protocols that use a ^tacket zero" and non-128- 
byte-packets (see the deKrtptkms below of the Tellnk and YMODEM protocols). 

Different tmplementatlMis lee different features, and futire Implementations may 
use still different features. There Is really no way, currently, to accomplish this 
reconciliation, in any existing protocol. 

Hiere k anothv proMem with most XMODEM-based irotocols, having to do 
with CRC error checking. Inmost lRq>lementatlons, a "C b sent by the receiver Instead 
of the first NAK, to signal CRC mode. If the transmitter hasn't re^xmded by the 
third "CT, the receive iwiicbes to cbeckswn mode, and sends a NAK. The tranmnltter 
preMHnably responds to thtt by amdlng the fkvt data packet, and the transfer continues 
In checksum mode. 

The timeout for the le^wnn to die K-' Is three seconds. Thus, die start of die 
transfer may be delayed by m much as nine or more seconds. If the trsnsmltto- doeai't 
support CRC error chec:klng. 

Some Existing Protocols 

Tliere is currently s proliferation cf new protocols, si! more-or-less loosely based 
on Christensen'spretocol. Most have fewures that are desirable. However, none of them 
have provided any really effective, long-tenn solution to the problems enumerated 
above, most of them ve to some degree Incompatible with Christenaen's original 
protocol, and most. If not ail, have added a level of complexity, to an originally simple 
protocol, that jrevents them from really taking hold In the user community the way 
Xl^dODEM has done. Some examples of these protocob Include MODEM? (originator 
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unknown), YKIODEM ((riglnated by Chuck Fcrsbcrg), end Tellnk (originated by Tom 
Jennings). There arc good and bad points about each of them. 

MODEM? uses a wy clionay and errrtr-prone method of trarsfo-rlng the file 
name, although this does allow batch flle transfers. 

YMODEM, used primarily on CP/M and UNIX systems, allows CRC error 
checking (usl[« the "C- Instead- of- a- NAK" method), 1024-byte data packets, and the 
transfer of file Information (filename, length, and date) In a "packet zem", allowing 
batch file transfers. A piT>blem extsta In the YMODEM protocol, however. In the area of 
the 1024-byte psckA length. According to the definition of the irotocol a 1024-byte 
packet Is prefixed with a STX rather than a SOH, and the recover must be able to handle 
any mU of 129- and 1024-byte packets. This use of STX as a data-packet prefix Is 
Inconsistent with the original simplicity of the XMODEM pnatocol. 

Tellnk uses the same clumsy method of transferring the file name thai la used In 
MODEM?, which is ironic, as Tellnk transfers the file name again In a "packet zen»", 
which also contains the file size and date, and Is prefixed with a SYN rather than an SOH 
(see the description, above, of the YMODEM protocol). Tellnk also provides CRC error 
checking, using [he \^ -Instead-of-a-NAK" method. 

Another protocol, which la not baaed on the XMODEM protocol, and which solves 
moat of the problems In that [rotocol (at the expense of a lot of added complexity), Is the 
Kernilt prottxrol. This prot(x:(d uaes "conmand packets" to set various parameters 
between the receiver and the sender. This protocol Is cxxnmonly used In university 
settlr^s, between mltrocoinputers and malnfrHiies. The protocol b Unix-based. The 
primary reason that Kermlt has not taken bold la becaiae of that added complexity. 
Kermit can be difficult and tedkwa to Implement, and the protocol has features that ate 
unneeded by most microcomputer users, as well at some restrictions not present In the 
XMODEM protocol. 

A New Protocol? 

Fine, you aay. Probleim exist. But Is a new protocol required, when there Is a 
huge (well, meybe not huge, but certainly large) proliferation of protocols. Wouldn't a 
new protocol Just add to the exlitliig meas? I say that a new protocol Is needed. It 
should not try to be all things to all people, as some existing protocob do, and It rfiould 
not compromlae the esaentlal simplicity of the original Chrlstensen XMOI3EM protocol, 
except where absolutely necessary, it should, however, allow the use of the new 
features of XMODEM-based Hie trarafer, such a> CRC error checking and large 
packet lengths. It rfiould attempt to allow file transfera with virtually any XMODEM- 
based ril^ transfo" protocol fanplentent at Ion, using the straight XMODEM protocol. It 
^ould also be as easily expendable as possible, In order to meet possible future needs. 

I propose a new protocol that would Incorporate the following features: 

1) NO IMPLEMENTATION SHOULD BE REQUIRED TO SUPPORT MORE T>1AN 
THE MINIMAL XMODEM FILE TRANSFER PROTOCOL, In terms of CRC error 
checking and packet lengths. This excepts the transfer of file infoimatlon. 

2) Transferof Hie Infonnatlon, ItKludIng filename, file size, and file date. The 
"packet zero" method? Vonmand packets", as In Kermlt? 

3) An easy way to let the receiver and transmitter agree on what features will be 
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used In the current transfer. This li the major problein ihst I lee with most of the 
current XMODEM-baaed protocols. This might be accompli^ied aeveral ways. One 
way would be trananltter -driven, using a V^cket zero" containing file Info and 
several bytes devoted to what features are supported. Another method might use 
Kermlt's solution to the problem, which Involves the receiver and the trananltter 
exchanging some kind of packet (a "conYnand packet") containing "feature -present" 
flags. The features used would be the exclualve-or of the "feature-present" flags. 
The packets might contain other Information, as well. 

4) The capability to support CRC error checking, without requiring such support. 
(That Is, It ^KHild allow CRC erivr checking, but It ihould not prohibit the checksun 
method.) 

5) The capability of udng longer or variable packet lengths to liKrease data 
throughput. (Variable -length packets would be easily Implemented by adding a 
control word to each packet containing the length of the packet. ) 

6) Batch file transfers. This rfiould be acconpllrfied easily. If Item 2 Is successfully 
accompll^ed. 

7) Full minimal XMODEM comfiaUblllty, as the default. This means no file 
Infonnatlon transfer, no CRC error checking, 128 -byte packets, and [» way for the 
receiver and trananltter to cofnmunlcate what features will be used (this last Is 
obvlous).This might be accompllrfied using the "C-lnstead-of-a-NAK" method, using 
some other character than C. Read '^" as NAK. 

8) The protocol tfiould be tecelver -driven, as much as possible. However, a method 
should exist to exploit d>e full capeblllttes of each end of the trwisfer. This 
requirement may be cdianged or removed, as It and Itesn 3 may prove to be mutually 
exdurive. 

9) Easy expandability. The protocol riiould Include mmtK method (such as reserved 
fields In conmand pecketsor In a ^wcket zero") for futuie expanshm. 

The full deTlnltlon of the protocol would lr>clude all the enhancements outlined 
above. As shown, the protocol would also allow subsets (Including a subset consisting of 
the OTlglnal XMODEM protocol), and would define a way to specify which set of 
enhanceiT«nts would be used for eadi transfer. 

There are a number of methods of satisfying these requtreinencs. I can see none 
that exactly fit the spirit of the original XMODEM Implementation and that completely 
eliminate all the problems mentioned In this document. However, It may not be possible 
to do both. I can see several possible solutions that do satisfy these requtronents, using 
features from several of the existing protocols, and some new features. 

Conclusion 

The problems mentioned In this document ere real, artd the great proliferation of 
file transfer protocols are not helping the matter. As I see It, some new protocol Is 
needed that Is a logical successor to XMODEM, that Incorporates most of the most -used 
features of the current protocols, and that Is as compatible as possible with existing 
protocols. I think that the the general outline above may provide such a protocol. 



-8- 



SOUTH BAY USLKS CROUP 

1 have not started tmplementlng this protocol, primarily because I don't »ant to go 
to all that wort and have it be completely Ignored. I would like to see the people most 
directly ^fected contribute their opinions and expertise to the solution of the problems 
I've mentioned. This means you, the public BBS iser. By no meara am I saying that the 
protocol I've outlined is THE solution. It ts merely a suggestion for one possible 
aolutton. However, I do believe that a solution Is needed, and soon. Obvk>usly no one 
protocol can be completely SBtlsfaciory to every permn In every situation. But we can 
conw up with a solution that solves most of the problems I've mentioned, and is also easy 
lo use and Implement. 

As I mentioned above, 1 would like to see a lot of people get Involved. My hope Is 
that we, the user cormiunlty, can get together and design and Implement a good new 
protocol, standardize tt, utd get It Into common use. If we can, perhaps the computer 
Industry, which has for the most part Ignored us (although there have been a few notable 
exceptions recently), will begin to view us a a teal Innovative and productive for^e In 
computing. 

Let me hear youroplnlons. 1 can be reached on the followtng BBS's: 

JImNet (Austin) RBBS at (512) 837-0953 -- This Is the one I use most. 

The Warbler (Wart>le2 FIDO, Dallas area) at (214) 52 

ON-Lir<£ WITH YOUR COMPUTER 

By Don Rhodes 

Your computer offers more than ■ meara to run programs In the local mode. You 
can use your computer to tie In with the WORLDI Connecting a modem and telephone to 
your computiT brings the outside world In to be divlayed on your screen or captured on 
your dldt. 

Presently there are more than a million people that use their computer lo 
jomnunlcate, exchange Ideea and obtain Information using their personal computer. I 
su^>ect that those that do not use (heir computa- for communlcatlorv, have some Idea 
that they don't know anyone that they can call If they did have the modem connected. 

If you do not call another computer, what Is the reason? Check one of the 
fdtowing answers: 

1 ) Don't want the expense of a modem 

2) Don't krtow who to call 

3) Don't like calling strangers 

4) I might look like an Idtot, If I did call aomewben. 

5) I don't want to tie tq> my phone by using the computer 

6) My r«8aonis: ??7 7?77 7 7? 

7) It'sB lot of work learning that stuff 

When 1 bought my first computer, I added the Modem liao-face and modem and a 
Tennlnal Program called VIdeoText. The computer dealer had bundled an application to 
Dow Jones News Service and an application to Compusfrve In with the Terminal program. 
All I had to do was Insert the diskette with the tennlnal program on it aixl press the 
START key to get the program going. From the Main Menu, I selected the Auto Log on 
for CompuServe and was connected within 5secon(fa to CompuServe where I filled out the 
on-line application and provided my Master Card credit card number. A few days later I 
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received a letter from CompuServe which provided me with my access password and 

account number. 

On- Line So* vices 
Initial - Baud / - 

Fee 300 1200 Members 



CompuServe $40 $6.00 $12.50 270,000 

The Source $50 $8.40 $10.60 60.000 

SBUG BBS $25 $0.00 $0.00 30 

* Charge pa* hoir at the specified baud rate. 

After the first month had passed, 1 received the bill from CompuServe and decided 
then that the expense of CompuServe was not within my budget and discontinued using 
the service. I read In the Sunday paper that there was a computer ukf club meeting the 
next Tuesday and decided to attend. My computing life changed from there on. The 
members In the club were very helpful and explained that they operate a Bulletin Board 
Service which I could call. 1 esked "what Is the Bulletin Eloard used for?" I was told 
that I could use It to keep tnfvmed on the activities of the club and to down load 
program files. I could also use It to upload programs that I had written or that 1 had 
obtained from somewhere else (non copy righted programs). 

The differeTKe between a commerctal service and a club BBS Is that I get to meet 
the people 1 exchange messages wtth and I can up and down load program files (files that 
arc In binary format, commercial services aie limited to ASCII text formatted Hies). 

Another benefit of using a BBS is getting a message to another member, even If 
that member is unavailable by phone. 1 just call the BBS and leave a ntessage. Usually by 
that evening, the member has logged on and rolled to the message, a given me a call. 
It's sort of like an answo'lng machine, except the messages can be composed tike a 
letter, then sent to the BBS. 

What we need next Is a BBS that can call the phone number of the addressee and 
^>eak the message Into the phone; a ulklng messge ^fi and account number. 



LIST OF COMPUTER BULLETIN BOARDS 
Updated Jenuery 25, 1986 

TRS-aOBovds... 

South Bey Users Group 253-6293 Color Board 

South Bey Users Group 292 -7284 Fldo Net 

Byte Benditsof America 374-3974 

Buccaneer Harbor 980 -0276 (Moved to L.A, 

Irian 'O War 243 2370 

(Coco Users SEC on Man '0 War) 

Shark'sHead 247-4810 

Delta Wing 370-6527 

Redwood Color Board 415/591 -7366 

Sysop: Brad Ryan 24hrs 

.Section 1. IBM PC BBS - South Bay Area - Area Code 408 
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.292-72S4 San Jose, CA Public BBS limited acc«u. 

.300/1200 baud. 24 hours. XMODEhl ULA^L. Meumgcs. 

•Sysops: Don Rhodes ft Gerry McKee 
.Usergroup: South Bey Usen Croup (SBUC) Tandy oiientatton. 

370-9187 San Jose, CA Oiccaneer's Cove 

300/1200 TBBS 144iT)bdl3k DLAJL Messages 
Many Sigs - Sysop: Red Beard 

735-7190 Sunnyvale, CA Public Domain 

Software Exchange 

300/450/1200 baud. 24 hours. XMODEM UL/DL. Mesiages. 

SysOps: Torn Shlnn and Gene Fuss 

735-7390 Sunnyvale, CA. LogOn Unlimited 

300/1200baud, 8-N-l, 24hr3, XMODEM DL of POSE NEW directory 
files, chat, messages, 3 lines Syst^s: Brad Kidder, Bob 
Sawyer, Lichen Wang 



972-4765 San Jose, CA PC TEE Sysop: Mark Chance 

300 baud, 8-N-l, 24hrs. XMODEM, UL/DL, PW 
.San Jose PC Computer Club 



735-6181 Sunnyvale, CA. Uving BBS Sysop: Bob Schakow 
300 baud 



745-6721 LosCatos.CA On-Llne Want Ada 

dBASEIIBBS 300/1200 8-N-l 



945-8358 San Jose, CA North San Jose RBBS 

300/450/1200 baud XMODEM UL/DL Messages 
SysOp: Doug Mulhalr 



225-1845 San Jose, CA RBBS 

Sysop: Gene Lowry 

300/450/1200 baud XMODEM UL/DL Messages 



356-0567 LosGatos.Ca F\iture Ftosltlve RBBS SysOp: 
300/450/1200 baud Xmodem UL/DL 



982-4044 Santa Clara, CA. Mainframe BBSSysop: Jim Sturlevant 300/1200 baud, E-7-1 
only. Use the commands In < to log onto this board: .<C/R 

Computer*? .<BaSC/R 
GO «C/R BBS C(1l 
Userid#: ..BBSC/R 
Id.paswd? <demo 



946-3269 San Jose, CA Sigma Designs RBBS 
Sysop: John Chan UL/DL Messages 



946-4933 Mllpltas, CA Quest .Sysop: Mike Ketcham 
1200 baud, XMODEM UL/DL, Messages, 
Genealogy Special Interest Group 
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733 1364 Sunnyvale, C A Crystal Castle 

Sysop: ManI* VIJ 

300/1200 baud, XMODEM ULrt5L. Messages, Many SIGs 

861-5733 San Francisco, CA. RBBS Sysop: Harry 
Logan 300/1200 baud, 6p - 8a wkdys, 24 hrs wknds, Xmodem, 
Upld/dwnld 



461 -0252 San Urenzo. CA. "No Naine RBBS' 

Sysop: Terry Taylor 

300/1200 baud, 24 hrs, Xmodem, Upld/dwnld 



937-0156 Walnut Creek, CA. WCRBBS Sysop; Wes Meier 
300/450/1200 baud, 24 hrs, UL/DL, XMODEM, Messages. 
Note: downloads disabled 5 -7pm. 



689-2090 Concord, CA AIRCOMM RBBS-PC Sysop: Jon Martin 
300/1200 baud, 24 hours. UL/DL, Messages. 



339-8457 East Bay The Exchange Sysop: Ann Meyer 
Interests: Recipes Can for Homeless Women's Interests 
Cwnputers 300 baud only. 8pm to Sam XMODEM/MesaagesAJL/DL 



829-8691 San Ramon, CA RBB5-PC 

Sysop: Norm McMullen 

300/1200 baud, 24 hours. UL/DL, Messages. 



327-6197 Palo Alto. CA ProgrMn-Land RBBS 

SysDp:James Arnold 

300/1200 baud, limited hours. ULA>L XMODEM Message. 



864-1418 San Francisco, CA FIDO RBBS Sysop: Tom 
Jennings 300/1200 baud. UL/DL XMODEM. 



974-6559 San Francisco, CA Friendly RBBS 

SysOp: John Sunmers 

300/1200 baud. Limited hours. Sections for TI and Apple 

users. 



793-9983 Risk Management and Insurance RBBS 
SysOp: Bob Herrlck 300/1200 baud. 11 pm - 6 pm. 



341 -2962 San Mateo, CA Computers for Christ RBBS 

SysOp: MarUn Fitch 

300/1200 baud. 24 hrs. UL/DL/XMODEM Messages 



895-9423 San Leandro, CA OSI RBBS Sysop: Craig Kim 
300/1200 baud. 6pm -Sam, weekdays, 24 hrs, weekends. 
UL/DL/XMODEM/Messages NOTE! Use RBBS as log-on password. 



838-7687 Danville, Ca DIABLO RBBS 

SysOps: Jeff & Phil 

300/450/ baud, 6p-llp wedtdays, 9p-I2p wkends UL/DL 
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.268-5157 Norad RBnS 
.300/450/1200 baud, SN-I, 
.UL/DL 20 megs 



Sy9op:Crcg Blls 
24 hrs Xmodem. 



.The AIhiio 224-8540 voice 8-7-85. 

.Big Foot 225-1845 no answer 8-7-85 

.Compuahop BBS 226 -4277 --answer 8-7-85 

.Ncmad M 227-9366 disconnect 8-7-85 

.Classified BBS 238-4017 voice 8-7-85 

.RCP/MRBBSServu 238-9621 

.Buccaneer's Man'O'War 243-2370 busy 1-7-86 

.RCP/M ZeeKfcchlne 245-1420 

.Pirates 246-7239 no answer 8 -7 -85 

.Crunal's Dimension 246-7854 no answer 8-7-85 

.RCP/M RBBB Santa ClBra....247-2853 

.SharV's Head 247-4810 off-line 'til Jan 16 

.Dark Tower 248-5135 disconnect 8-7-85 

.Hacker's Hangout 248-6518 no answer 8-7-85 

.Rat's Nest 249-6946 atari 

J^ffordable flarixir 249-7599 ck'd 8/85 

.RCP/M Z-nod3e Dlgitror.. ..253-1309 

.Random BBS 253-1384 an s machine 8-7-85 

.Twilight Zone 253-2140 no answer 8-7-85 

.Iron Maiden 253-5123 buiy 8-7-85 

JVtari C»AFEX 253-5216 

.General Store 253-8528 no answer 8-7-85 

.Tavern 255-7571 answered 8-7-85 



.Caverns o f Atlantis 257 -6115 

.Iron Works 257-7147 

.RCP/M RBBSAmpro Users.. ..258 -8128 

.Trivia 259-4030 

.Ghost Ship 259-7194 

.Wang Bang 263-1345 

.Oxgate 2 263-2588 

.Starbase 267-3558 

.Devil's Domain 268-2660 

.Social Impact Research. ...269-7045 

.EHal -A -EJeal 272-0283 

.USS Apple 281-0344 

.West -Coast Underground. ...286-4031 

.[Joghouse 287-9996 

.ATARI Forem 289-9151 

.ny Of Nig^t 293-6207 

.RCP/M Skyhouse Systems. .. .296 -5078 

J^MK IBBS 298-6930 

.Lambda Switchboard 298-6969 

.Stewart 11 338-9511 

.Metropolis BBS 353-1553 

.RCP/M Oxgate Sara toga 354-5934 

.Bey City 364-8517 

.Delta Wing 370-6527 

.The Animal House 374-0966 

.Byte Bandits 374-3974 



.RCP/M Oxgate.Potpouri 378-7474 

.Diatbase 2 378-8733 

.RCP/M Slmnia 732-9190 

.RBBS RonTech 773-9880 

.RCP/M RBBS Elgenware 867-6575 

.C8ltex-99 926-8767 

.RBBS-PC North San Jose. ...945 -8358 

.ABBS 415-284-9524 

.Uvlng BBS 415-327-8876 

.INFO-NET 415-349-3126 

.lAC Message Base 415-367-1339 

.RCP/M 415-383-0473 

. h6 415-462-7419 

.Conference Tree 1 415-526-7733 

.Conference Tree 3 415-538-3580 

.Kinky Kumputer 415-552-8268 

-ABBS 415-585-6334 

.Oasis 415-591-5509 

.Aardwolf 415-651-4147 

.CBBS 415-658-2919 

.ABBS 415-794-9314 

.Homy Mag Service 415-845-2079 

-PMS 415-851-3453 

-ABBS 415-863-4703 

.ABBS 415-881-5662 

.Conference Tree 2 415-928-0641 
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.RCP/M 4I5-M9-2563 

.RCP/M 4I5-WS-4097 

.Tamarlane's Keep 429-1995 

.Conference Tree 475-7101 

.The Wall 554-0602 

.Meritn's Castle 578-1563 

.Moondog 578-2266 

.BAAUG 578-2390 

.RCP/M RBB5 SkyhouBSys... 578 -6185 

.T.l. Club 578-6264 

.Caltex 12 578-6264 

.Mlcrobur 629-22n 

.Tamariane 662-1810 

.Tamarilne's'Keep 668-9629 

.Mines of MDria 688-9629 

.RCP/M Sunnyvale 730-8733 

-Van Vision 732-1079 

.Oracle RCP/M 732-9190 

.Crystal Castle 733-1364 

.Rainbow COCO BBS 733-6809 

.Blackwood's Castle 736-3384 

.Old SBUG Number 737-7284 

.Atari BBSl 739-5370 

.Anything Goes 745-7524 

.Caltex 794-80S0 

.Atari BBS 2 866-4224 



Appier 1 866-6330 

.Scavenger BBS 867-7982 

.T.l. Stick 926-4413 

.CalMx 926-8767 

.Calrex 926-8767 

.Realm of the .Rogues 941 -1990 

.Nwofriinu II 941-3831 

.Haunted House .....941-7256 

.Rmi-Page 945-1569 

.North San Jose BBS 945-8358 

.Green Machine 946-2179 

.MRC 968-6501 

.nanet Earth 968-7728 

.PsIadlnTocA'sAE. 978-7037 

.Bucaneer Hartior ,.980-0276 

.Rainbow 984-7937 

.Software Spa tchers 986-8685 

.Shadow AE..Pass:SHADOW... .996- 
1137 

.Dtagon't Lair 996-7464 

.ShMlln Temple 997-0440 

.Tile Crsveyanl 997-1175 

.Color 80 997-2790 

.Battleground 997-3341 

.Buccaneer's Brlganttne ...997-3486 



Prom InfoWorld... 02/1V86 

PC Users Claim Memory Bovdi Have Problenis... 

It seems that users have encountered froblems udng the expanded memory boaids 
(the one that go beyond 640k). Speed up boards that use the Cache technique cannot 
address the expanded memoty locations. 

Memory Expansions. 

The expanded memory bovdi standsrd was developed tqr Lotus/ Intel/ Mlcrosofi 
and orfers access up to 8mb of Ram. Intel's 'Above Boartf Is one of these memory 
expansion boards Call 800-S38-3378 ftx Info. AST's Rampage memory exparaion to 2mb 
Ram/board takes a slightly different approach. It offers a Stqierset of the yecincatlon. 

What is Excel? Produced by Microsoft, Excel Is a spreadsheet for the MAC. It 
composes 31% of MIcKiaoft's software business. 

New Lap Top uses MsDos and Xenix. The 32 bit 32032 cpu computer from 
Compucorp, Santa Monica hsa 360k floppy and 20inb hard (h-lves with 1.64 mb Ram. 
Priced at only $4,995. 

Windows... What Is It? Windows by Microsoft Is a user Interface program 
requiring about 1.5 mb of disk space and at least 640fc to be usable. The ^eed of 
execution Is about as good as a turtle In a rabUt race. But then so Is their word 
processor: WORD. 
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